| # RMI Release Notes for J2SETM 1.4 | Documentation Contents

Known Problems in J2SETM 1.4

> `IllegalStateException` trace output by RMI server virtual machine
>   When a virtual machine with exported remote objects is receiving remote calls under heavy load, an exception trace similar to the following may be output occasionally to `System.err`:

>   >     java.lang.IllegalStateException: Task already scheduled or cancelled
>   >             at java.util.Timer.sched(Timer.java:316)
>   >             at java.util.Timer.schedule(Timer.java:128)
>   >             at sun.rmi.transport.DGCAckHandler.startTimer(DGCAckHandler.java:84)
>   >             at sun.rmi.transport.ConnectionOutputStream.done(ConnectionOutputStream.java:82)
>   >             at sun.rmi.transport.StreamRemoteCall.releaseOutputStream(StreamRemoteCall.java:94)
>   >             at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:302)
>   >             at sun.rmi.transport.Transport$1.run(Transport.java:148)
>   >             at java.security.AccessController.doPrivileged(Native Method)
>   >             at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
>   >             at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
>   >             at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
>   >             at java.lang.Thread.run(Thread.java:536)

>   Usually, the occurrence of this exception is otherwise harmless, although in some cases when clients attempt remote calls in rapid succession, the occurrence of the above exception can cause one future client remote call to fail with a `java.rmi.UnmarshalException` containing a `java.io.EOFException`. When this occurs, retrying the failed remote call will succeed. This problem will be fixed in the next maintenance release.

RMI Enhancements in J2SETM 1.4

> Server-side Stack Traces Now Retained in Remote Exceptions
>   The RMI runtime implementation will now preserve the server-side stack trace information of an exception that is thrown from a remote call, in addition to filling in the client-side stack trace as it did previous releases. Therefore, when such an exception becomes accessible to client code, its stack trace will now contain all of its original server-side trace data followed by the client-side trace.

>   This feature is made possible by the new "programmatic access to stack trace information" feature of `java.lang.Throwable` in J2SE 1.4, which included making a Throwable's stack trace data part of its default serialized form. What the client-side RMI runtime implementation now does to cooperate with this feature is to append the client-side trace to the unmarshalled server-side trace, rather than simply overwriting with the client-side trace as it did in previous releases.

>   Certain RMI server applications may wish to prevent any server-side stack trace data from accompanying an exception to be marshalled as the result of a remote call (as part of the exception's default serialized form in J2SE 1.4), perhaps for reasons of performance or confidentiality. In such cases, the implementation-specific system property

>   >     sun.rmi.server.suppressStackTraces

>   can be set to "true" to cause the server-side RMI runtime implementation to clear the stack traces of all exceptions thrown from the current virtual machine as the result of remote method invocations.

> Service Provider Interface for `RMIClassLoader`
>   Certain static methods of `java.rmi.server.RMIClassLoader` now delegate their behavior to an instance of a new service provider interface, `java.rmi.server.RMIClassLoaderSpi`. The service provider can be configured to augment RMI's dynamic class loading behavior for a given application. By default, the service provider implements the standard behavior of all of the static methods in `RMIClassLoader`. See the class documentation of `RMIClassLoader` and `RMIClassLoaderSpi` for more details.

> Dynamic Server Host Name
>   The `java.rmi.server.hostname` property can now be dynamically updated to indicate that future exports should use a new host name. Therefore, the new host name value will be contained in the stub for an object that is exported after the property is updated.

> Serializing Primitive Class Objects
>   In previous releases, a `ClassNotFoundException` would be thrown if an attempt was made to pass a primitive `Class` object in an RMI call. Now, an object that contains `Class` objects for primitive types can be passed as a remote method parameter or return value, and can be stored in a `java.rmi.MarshalledObject` instance.

> Enhanced RMI Implementation Logging
>   Sun's implementation of RMI in J2SE 1.4 now uses the new Logging APIs to provide implemention-specific logging output. See the RMI Implementation Logging page for more information.

> Serialization Enhancements
>   See the Serialization Release Notes for more information on enhancements and improvements to Object Serialization in J2SE 1.4.

RMI Enhancements in Previous Releases

> `java.rmi.activation.ActivationGroupDesc` (since 1.3)
>   The `getClassName` method, which returns the group's class name, can now return `null`, indicating the system's default group implementation. Previously, the `getClassName` method would return the name of the internal implementation class if the default group implementation was chosen when the descriptor was constructed.

>   Due to this change, if an application running in a 1.3 JVM registers an new activatable object with the `ActivationSystem`, `rmid` must also be upgraded to run 1.3, since a pre-1.3 `rmid` will not be able to activate the newly registered activatable object.

> Constructors of activatable objects (since 1.3)
>   An activatable object's "activation" constructor, which takes an `ActivationID` and a `MarshalledObject`as arguments and which is called by the `ActivationInstantiator` each time the object is activated, can now be `private` or `protected`. Previously, the implementation only allowed `public` activation constructors.

> Serializing remote objects (since 1.2.2)
>   Prior to 1.2.2, an attempt to pass an unexported remote object in a RMI call would result in a `java.rmi.StubNotFoundException`. This exception was a result of the RMI runtime's failure to locate a stub object during an attempt to replace a remote object implementation with its corresponding stub. In 1.2.2 and later releases, an unexported remote object passed in an RMI call will no longer result in an exception, but rather the remote object will be serialized instead of its stub. If the remote object implementation is not serializable, an attempt to pass an unexported object in an RMI call will result in a `java.rmi.RemoteException` with the nested exception `java.io.NotSerializableException`.

> `java.rmi.server.RMIClassLoader` (since 1.3)
>   `java.rmi.server.RMIClassLoader` has a new method, `getClassLoader`. This method returns the class loader that RMI uses to load classes from a specified codebase URL path. This API can be used in an implementation that requires complete RMI marshalling/unmarshalling behavior. See `java.rmi.server.RMIClassLoader` for details.

Changes to RMI Tools (since 1.3)

The RMI Stub Compiler, `rmic`

- By default, `rmic` now assumes that the destination directory for generated stubs is the package-named subdirectory of the current working directory. If the "`-d`" option is not specified, the result is the same as though it were specified with the current working directory "." as an argument. The "`-d`" may still be used to override the default destination directory.
- Two new options, "`-idl`" and "`-iiop`" have been added to generate IDL and stubs for IIOP, respectively.

The RMI Activation Daemon, `rmid`
  By default, `rmid` now requires a security policy file.

*As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.

Copyright © 2001 Sun Microsystems, Inc. All Rights Reserved. Please send comments to: rmi-comments@java.sun.com |